x86 svm: Fix checked builds of Windows running on AMD SVM

Checked builds of Windows will, after every modification of the TPR,
read it back again and assert that the value read back matches with
the value written, including the priority sub-class.  Make sure that
we correctly preserve it on vmexit.

As far as I can tell from reading the documentation, the sub-class
doesn't actually do anything, so this should be pretty harmless.

Signed-off-by: Steven Smith <steven.smith@eu.citrix.com>

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 6236ead0beccc8f8c70f79d58a69a18af3cee893..7c9aaadb0b26ed70d27b59e5434661f3f256addc 100644 (file)
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1306,9 +1306,12 @@ asmlinkage void svm_vmexit_handler(struct cpu_user_regs *regs)
      * Before doing anything else, we need to sync up the VLAPIC's TPR with
      * SVM's vTPR. It's OK if the guest doesn't touch CR8 (e.g. 32-bit Windows)
      * because we update the vTPR on MMIO writes to the TPR.
+     * NB. We need to preserve the low bits of the TPR to make checked builds
+     * of Windows work, even though they don't actually do anything.
      */
     vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
-                   (vmcb->vintr.fields.tpr & 0x0F) << 4);
+                   ((vmcb->vintr.fields.tpr & 0x0F) << 4) |
+                   (vlapic_get_reg(APIC_TASKPRI) & 0x0F));
 
     exit_reason = vmcb->exitcode;